The IP multicast means that a packet is sent to a specific node subset in a network in a best-effort mode, where the subset is called a multicast group. The basic principles of the IP multicast are:
A source host sends only one copy of data. The destination address in the data is a multicast group address; and
all receivers in the multicast group can receive the same data copy, and the data is receivable by only the host in the multicast group, namely, the target host, rather than any other host in the network.
As regards the single-point-to-multipoint issue, the IP multicast technology provides an effective solution, implements efficient data transmission from a single point to multiple points in the IP network, saves the network bandwidth massively, and reduces the network load. As parallel to unicast and broadcast, multicast provides more important features. For example, the multicast feature of the network may be used to launch new Value-Added Services (VASs) conveniently, including the Internet information services such as live broadcast, IPTV, tele-education, telemedicine, network broadcasting station, and real-time videoconference.
Protocol Independent Multicast-Sparse Mode (PIM-SM) and Source-Specific Multicast (SSM) are two common intra-domain multicast modes. Under these two modes, the multicast packet is forwarded by creating a multicast distribution tree. However, in the case that multiple routers coexist in a shared network segment, the downstream router receives multiple duplicate copies of data if all the routers forward the data to this network segment. Therefore, one of the routers needs to be selected as a Designated Router (DR) in the network segment, and the DR is responsible for forwarding data to the network segment. If none of the interfaces of the routers connected to a user terminal enables the PIM SM or SSM, a router is selected as an interrogator via the Internet Group Management Protocol (IGMP) mechanism. The interrogator is responsible for forwarding data to this network segment.
As shown in FIG. 1, the network includes: a user terminal 18, a source host 11, a switch 12, a switch 17, and four routers RTA 13, RTB 14, RTC 15, and RTD 16. The user terminal 18 is connected with RTC 15 and RTD 16 through the switch 17. Both RTC 15 and RTD 16 can receive the IGMP report sent by the user, and are involved in the DR selection. If the RTC 15 is selected as a DR or interrogator, the RTC 15 becomes a first router responsible for forwarding data. In this case, the RTD 16 serves as a second router, namely, a standby DR or interrogator, and does not forward data in normal circumstances. Likewise, if the RTD 16 is selected as a DR or interrogator, the RTD 16 becomes the first router and is responsible for forwarding data, and the RTC 15 serves as a second router, namely, standby DR or standby interrogator, and does not forward data in normal circumstances.
As shown in FIG. 2, after the data forwarding begins, it is supposed that the DR or interrogator, namely, RTC 15 in FIG. 2, fails. The RTD 16 discovers the fault of the first router RTC 15 through a fast detection mechanism such as Bidirectional Forwarding Detection (BFD), and RTD 16 becomes a DR or interrogator and is responsible for forwarding data. In this case, the data sending mode is illustrated in FIG. 3. The arrowhead in FIG. 3 indicates the direction of sending the data along the standby path in the case of RTC 15 failure.
As shown in FIG. 4, the RTC 15 recovers from failure. The RTD 16 receives a HELLO (handshake) packet or IGMP interrogation packet from the RTC 15, and becomes a non-DR or non-interrogator and stops forwarding data. However, the RTC 15 has not obtained the IGMP report message or the upstream router has not forwarded the data, and therefore, the RTC 15 does not forward the data. Consequently, once a fault occurs, the traffic is interrupted twice.
To tackle such problems, a sticky-dr (priority dr-priority) solution is put forwarded currently. In the solution, sticky-dr is configured through a command line interface. Once a router is selected as a DR, its priority is set to the configured value. In this way, it is not possible for the original active DR to be selected as a new DR after the original active DR is restarted. The selected new DR continues forwarding the data along a new path.
Therefore, in the foregoing scenario, the data is forwarded along this path: source host-switch-RTA-RTB-RTD-switch-user terminal after the fault is cleared. The forwarding direction is the same as the direction indicated by the arrowhead in FIG. 3.
The multicast service generally involves high traffic and occupies plenty of bandwidth. Therefore, in the network deployment, the operator generally plans the forwarding path, for example, RTA-RTC. For the purpose of disaster recovery, a standby path, for example, RTA-RTB-RTD, is reserved. In normal circumstances, the standby path, such as RTB or RTD, bears other services. Once the RTC fails, switch to the standby path for data transmission temporarily. After the fault is cleared, switch to the active path for data transmission, without occupying the standby path permanently. However, the sticky-dr solution is implemented by increasing priority. It is not possible for the original active DR to be selected successfully, and therefore, the standby path is occupied permanently.